It seems like if I try to define more than one top-level variable using evalTop_ from within a trigger, only the first definition works; the rest behave strangely.
For example, suppose I install a trigger as follows.
string sTrigger =
"print \"Starting trigger 1\\n\";\n" //-
"evalTop_ (\"int Foo1 = 1\");\n" //-
"evalTop_ (\"int Foo2 = 2\");\n" //-
"evalTop_ (\"print \\\"Foo1 = \\\" Foo1 \\\"\\\\n\\\"\");\n" //-
"evalTop_ (\"print \\\"Foo2 = \\\" Foo2 \\\"\\\\n\\\"\");\n" //-
"print \"Ending trigger 1\\n\";\n"
print sTrigger // Sanity check
delete ("OnModuleOpen_MakeGlobalVars", module->"T1_SRD", post, open, 2)
trigger ("OnModuleOpen_MakeGlobalVars", module->"T1_SRD", post, open, 2, sTrigger)
This gives the following output.
print "Starting trigger 1\n";
evalTop_ ("int Foo1 = 1");
evalTop_ ("int Foo2 = 2");
evalTop_ ("print \"Foo1 = \" Foo1 \"\\n\"");
evalTop_ ("print \"Foo2 = \" Foo2 \"\\n\"");
print "Ending trigger 1\n";
Now when I open the module I get the following output:
Starting trigger 1
Ending trigger 1
Foo1 = 1
Foo2 = 2
But if I subsequently type the following in the DXL Interaction window:
print "Foo1 = " Foo1 "\n"
print "Foo2 = " Foo2 "\n"
then I get:
Foo1 = 1
-R-E- DXL: <Line:2> unassigned variable (Foo2)
-I- DXL: execution halted
I've tried three variables, with the same results -- only the first one works. I've tried using different triggers (one trigger per variable) with the same results. It seems like I can only define one variable at the top level from within a trigger. I have only been trying the Module Post Open trigger; I have not tried any others.
I am using DOORS 9.3.0.6 Build number 93576.
Am I doing something wrong?
JoelKuehner - Tue Jun 05 23:59:09 EDT 2012 |
|
Re: Multiple evalTop_ variable declarations in trigger
llandale - Wed Jun 06 14:45:00 EDT 2012
Well first of all, using evalTop_ can rarely be right; you are changing your DXL environment for the rest of the DOORS session.
If I were going to mess with it, I'd have the trigger first determine if the variables and functions are already defined; use "eval_" with some statement that refers to them; and if it returns no errors then they are already defined; otherwise go ahead and defined them with evalTop_.
Back to your problem here; sorry don't know.
|
|
Re: Multiple evalTop_ variable declarations in trigger
JoelKuehner - Wed Jun 06 15:04:39 EDT 2012 llandale - Wed Jun 06 14:45:00 EDT 2012
Well first of all, using evalTop_ can rarely be right; you are changing your DXL environment for the rest of the DOORS session.
If I were going to mess with it, I'd have the trigger first determine if the variables and functions are already defined; use "eval_" with some statement that refers to them; and if it returns no errors then they are already defined; otherwise go ahead and defined them with evalTop_.
Back to your problem here; sorry don't know.
If you look at my original post, I tried to clearly show the variables being assigned and having values, then subsequently being determined as being unassigned by DOORS. If you execute the same code from the DXL Interaction window instead of from a trigger, everything works fine. So something is strange between evalTop_ and triggers. That's what I'm asking about.
|
|
Re: Multiple evalTop_ variable declarations in trigger
llandale - Wed Jun 06 17:41:03 EDT 2012 JoelKuehner - Wed Jun 06 15:04:39 EDT 2012
The eval_ approach that you suggest does not work with variables that are unassigned; it checks whether variables exist, not whether they are assigned. Unassigned is different from not existing. noError() will not suppress the unassigned message. The eval_ approach says (rightly) that the variables exist in the case I gave. The variables exist; they have just lost their values. So the eval_ approach does not help at all.
If you look at my original post, I tried to clearly show the variables being assigned and having values, then subsequently being determined as being unassigned by DOORS. If you execute the same code from the DXL Interaction window instead of from a trigger, everything works fine. So something is strange between evalTop_ and triggers. That's what I'm asking about.
-
if(my clever eval_ comes back with errors)//
-
then install evalTop_ code
-
else do nothing.
But for your problem, I known see why it would do that. If it were me I'd wait for Mathias to see this thread.
-Louie
|
|
Re: Multiple evalTop_ variable declarations in trigger
Mathias Mamsch - Thu Jun 07 09:23:53 EDT 2012 JoelKuehner - Wed Jun 06 15:04:39 EDT 2012
The eval_ approach that you suggest does not work with variables that are unassigned; it checks whether variables exist, not whether they are assigned. Unassigned is different from not existing. noError() will not suppress the unassigned message. The eval_ approach says (rightly) that the variables exist in the case I gave. The variables exist; they have just lost their values. So the eval_ approach does not help at all.
If you look at my original post, I tried to clearly show the variables being assigned and having values, then subsequently being determined as being unassigned by DOORS. If you execute the same code from the DXL Interaction window instead of from a trigger, everything works fine. So something is strange between evalTop_ and triggers. That's what I'm asking about.
Hi Joel,
for DOORS 9.3.0.0.93199 i cannot reproduce the error. Here the Foo1 and Foo2 print alright. I think I will update to patch level 9.3.6 or 9.3.7 and see if the error persists. By the way, the way Louie suggests should be fine to test if a variable has already been installed on top level:
string sCode = "print Foo1"
noError(); string errMsg = eval_ sCode; string errMsg2 = lastError();
if (errMsg errMsg2 != "") print "Variable Foo1 has not been installed.\n"
Although it might not seem to be different for you can you change your code to:
The first thing that makes me courious is the fact, that when I install the trigger code and then subsequently open and close the module multiple times, then
-
the first time I get the correct printout
-
the second time I get "Foo1 already declared" etc errors
-
the third and all following times time I get the correct printout again.
Couriously when I delete the trigger and install the trigger again with different values for Foo1 and Foo2 they are printed with the NEW values instead of the old ones. What happens when you open/close the module multiple times? From what I see this code will do something to the DXL engine that is not good. Being able to declare the same variable on top level multiple times is not what I would expect.
By the way, what are you trying to accomplish? Install global variables in a script? For what purpose?
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|
Re: Multiple evalTop_ variable declarations in trigger
JoelKuehner - Thu Jun 07 11:04:03 EDT 2012 Mathias Mamsch - Thu Jun 07 09:23:53 EDT 2012
Hi Joel,
for DOORS 9.3.0.0.93199 i cannot reproduce the error. Here the Foo1 and Foo2 print alright. I think I will update to patch level 9.3.6 or 9.3.7 and see if the error persists. By the way, the way Louie suggests should be fine to test if a variable has already been installed on top level:
string sCode = "print Foo1"
noError(); string errMsg = eval_ sCode; string errMsg2 = lastError();
if (errMsg errMsg2 != "") print "Variable Foo1 has not been installed.\n"
Although it might not seem to be different for you can you change your code to:
The first thing that makes me courious is the fact, that when I install the trigger code and then subsequently open and close the module multiple times, then
-
the first time I get the correct printout
-
the second time I get "Foo1 already declared" etc errors
-
the third and all following times time I get the correct printout again.
Couriously when I delete the trigger and install the trigger again with different values for Foo1 and Foo2 they are printed with the NEW values instead of the old ones. What happens when you open/close the module multiple times? From what I see this code will do something to the DXL engine that is not good. Being able to declare the same variable on top level multiple times is not what I would expect.
By the way, what are you trying to accomplish? Install global variables in a script? For what purpose?
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
Thanks for responding. I appreciate you chiming in.
I just want to be clear here that I do normally use the eval_ check to first check if a variable is installed. I didn't include it in my original post because I was showing the exact steps to reproduce my issue in the original post. The eval_ part isn't necessary to reproduce the issue. But normally, I have a Module-Post-Open trigger that simply checks if the variables are installed, and installs (and initializes) them if they're not.
With respect to the eval_ solution for checking if a variable is installed, I tried the exact code you suggested (which was basically the same as code I've already been using, since I got that code from one of these forums -- probably one of your posts -- a while back). It does not help. It checks if a variable has been installed, but doesn't help if the variably simply isn't assigned.
So it works if you use evalTop_ ("int Foo1 = 1"), but try it if you simply use evalTop_ ("int Foo1"). Now I realize that just doing "int Foo1" is not a good idea. But I'm not (intentionally) doing that. I'm issuing "int Foo1 = 1" in the trigger I mentioned above, but DOORS is taking away the assignment (after the evalTop_ completes) such that the variable is still installed but not assigned. So later I run the eval_ check, it tells me the variable is installed, I assume it's assigned (since I assigned it when I installed it), but since it's no longer assigned, I get the "unassigned variable" runtime error. As a matter of fact, the eval_ check itself gives me the run-time error when it executes the "print Foo1". Feel free to try it! Just issue an evalTop_ ("int Foo1"), then try your eval_ check and see what happens. You'll get the run-time error.
As to what I'm trying to accomplish, I will answer it, but please don't let this thread get off onto a philosophical debate about why I'm doing it. I know there are multiple solutions, but at this point I really want to focus on why DOORS is behaving like it is, rather than whether I should philosophically be using the evalTop_ in the first place. Though, depending on the outcome of this thread, I might decide not to use the evalTop_ for other reasons (i.e., it's broken). :)
I am simply trying to install some global variables. We have our own change-tracking functionality implemented. It uses a global variable to track which ChangeRequest the user is working against. That variable is initialized via a dialog box based on a module open trigger. That is all working great.
Then I wanted to add another modeless dialog box that opens when the module opens. Basically it's a floating custom menu to go along with the change-tracking. I wanted to use another global variable to track whether the dialog box exists. Basically, set a flag when the dialog box is created, clear the flag when the dialog box is closed. That way, later, if it's time to possibly re-open the dialog box, I query the global variable to see whether the dialog box already exists, in which case I just show it instead of re-creating it.
When I went to add the second flag, I was getting strange behavior, and spent about a day tracking it down. I went down lots of bunny-trails related to modal vs modeless, show() vs realize(), one trigger vs multiple, etc. Eventually I tracked it down to the issue I mentioned in my original post -- my evalTop_ variables that are installed via trigger are losing their assignments (all except the first). The dialog box and its context(s) have nothing to do with it.
We use DOORS in several sites in North America, Europe and India, sometimes on the desktop, sometimes remotely via Citrix (which we DOORS users have not admin access to), and in the future hopefully using web access. So I shy away from custom installations with custom startup files or custom menus, because it's somewhat difficult to maintain the configuration on all of those different platforms for different programs. It's often easier to just use triggers when the module is opened to set up whatever we need. We basically run a trigger install dxl script that reads our include files using fileRead(), concatenates them together with the trigger function, and installs that as the trigger. So no custom local or network files are necessary at all.
It would be great if you could install 9.3.0.6 (or 9.3.0.7) and let me know what you see. I expect you'd see the same as I do. Though even the results you cite are strange, and don't give me much confidence when using evalTop_ from triggers.
|
|
Re: Multiple evalTop_ variable declarations in trigger
JoelKuehner - Thu Jun 07 11:54:59 EDT 2012 JoelKuehner - Thu Jun 07 11:04:03 EDT 2012
Hi Mathias,
Thanks for responding. I appreciate you chiming in.
I just want to be clear here that I do normally use the eval_ check to first check if a variable is installed. I didn't include it in my original post because I was showing the exact steps to reproduce my issue in the original post. The eval_ part isn't necessary to reproduce the issue. But normally, I have a Module-Post-Open trigger that simply checks if the variables are installed, and installs (and initializes) them if they're not.
With respect to the eval_ solution for checking if a variable is installed, I tried the exact code you suggested (which was basically the same as code I've already been using, since I got that code from one of these forums -- probably one of your posts -- a while back). It does not help. It checks if a variable has been installed, but doesn't help if the variably simply isn't assigned.
So it works if you use evalTop_ ("int Foo1 = 1"), but try it if you simply use evalTop_ ("int Foo1"). Now I realize that just doing "int Foo1" is not a good idea. But I'm not (intentionally) doing that. I'm issuing "int Foo1 = 1" in the trigger I mentioned above, but DOORS is taking away the assignment (after the evalTop_ completes) such that the variable is still installed but not assigned. So later I run the eval_ check, it tells me the variable is installed, I assume it's assigned (since I assigned it when I installed it), but since it's no longer assigned, I get the "unassigned variable" runtime error. As a matter of fact, the eval_ check itself gives me the run-time error when it executes the "print Foo1". Feel free to try it! Just issue an evalTop_ ("int Foo1"), then try your eval_ check and see what happens. You'll get the run-time error.
As to what I'm trying to accomplish, I will answer it, but please don't let this thread get off onto a philosophical debate about why I'm doing it. I know there are multiple solutions, but at this point I really want to focus on why DOORS is behaving like it is, rather than whether I should philosophically be using the evalTop_ in the first place. Though, depending on the outcome of this thread, I might decide not to use the evalTop_ for other reasons (i.e., it's broken). :)
I am simply trying to install some global variables. We have our own change-tracking functionality implemented. It uses a global variable to track which ChangeRequest the user is working against. That variable is initialized via a dialog box based on a module open trigger. That is all working great.
Then I wanted to add another modeless dialog box that opens when the module opens. Basically it's a floating custom menu to go along with the change-tracking. I wanted to use another global variable to track whether the dialog box exists. Basically, set a flag when the dialog box is created, clear the flag when the dialog box is closed. That way, later, if it's time to possibly re-open the dialog box, I query the global variable to see whether the dialog box already exists, in which case I just show it instead of re-creating it.
When I went to add the second flag, I was getting strange behavior, and spent about a day tracking it down. I went down lots of bunny-trails related to modal vs modeless, show() vs realize(), one trigger vs multiple, etc. Eventually I tracked it down to the issue I mentioned in my original post -- my evalTop_ variables that are installed via trigger are losing their assignments (all except the first). The dialog box and its context(s) have nothing to do with it.
We use DOORS in several sites in North America, Europe and India, sometimes on the desktop, sometimes remotely via Citrix (which we DOORS users have not admin access to), and in the future hopefully using web access. So I shy away from custom installations with custom startup files or custom menus, because it's somewhat difficult to maintain the configuration on all of those different platforms for different programs. It's often easier to just use triggers when the module is opened to set up whatever we need. We basically run a trigger install dxl script that reads our include files using fileRead(), concatenates them together with the trigger function, and installs that as the trigger. So no custom local or network files are necessary at all.
It would be great if you could install 9.3.0.6 (or 9.3.0.7) and let me know what you see. I expect you'd see the same as I do. Though even the results you cite are strange, and don't give me much confidence when using evalTop_ from triggers.
Mathias,
Sorry; I meant to include the results of trying your code explicitly.
After opening the module, which invokes the trigger, I ran the following from the Dxl Interaction window:
string sCode, errMsg, errMsg2
sCode = "print Foo1"
noError(); errMsg = eval_ sCode; errMsg2 = lastError();
if (errMsg errMsg2 != "") print "Variable Foo1 has not been installed.\n"
sCode = "print Foo2"
noError(); errMsg = eval_ sCode; errMsg2 = lastError();
if (errMsg errMsg2 != "") print "Variable Foo2 has not been installed.\n"
And I got the following result:
1
-R-E- DXL: <Line:1> unassigned variable (Foo2)
-I- DXL: execution halted
|
|
Re: Multiple evalTop_ variable declarations in trigger
llandale - Thu Jun 07 13:35:16 EDT 2012 JoelKuehner - Thu Jun 07 11:54:59 EDT 2012
Mathias,
Sorry; I meant to include the results of trying your code explicitly.
After opening the module, which invokes the trigger, I ran the following from the Dxl Interaction window:
string sCode, errMsg, errMsg2
sCode = "print Foo1"
noError(); errMsg = eval_ sCode; errMsg2 = lastError();
if (errMsg errMsg2 != "") print "Variable Foo1 has not been installed.\n"
sCode = "print Foo2"
noError(); errMsg = eval_ sCode; errMsg2 = lastError();
if (errMsg errMsg2 != "") print "Variable Foo2 has not been installed.\n"
And I got the following result:
1
-R-E- DXL: <Line:1> unassigned variable (Foo2)
-I- DXL: execution halted
Perhaps you need a program to find and delete triggers. Something I must say is SADLY absent from the GUI menus.
-Louie
|
|
Re: Multiple evalTop_ variable declarations in trigger
JoelKuehner - Thu Jun 07 13:52:51 EDT 2012 llandale - Thu Jun 07 13:35:16 EDT 2012
I wonder if you've been practicing with this for a while and have some other residual trigger that does this: evalTop_("int Foo2"). THAT trigger is also firing after THIS trigger, and the print statements see the undefined variable.
Perhaps you need a program to find and delete triggers. Something I must say is SADLY absent from the GUI menus.
-Louie
The original problem was happening with variables named something other than "Foo1" and "Foo2". I don't really use variable names "Foo1" and "Foo2" in my code. :) When debugging, I changed to "Foo" names explicitly for the reason you cite - in case something else was going on with the other variable names.
After I tracked things down, I did the whole "Foo" thing on a new module to support this thread. That module is very bare. This morning, on this new module, I did a loop to print all triggers, and this one trigger was the only one installed.
|
|
Re: Multiple evalTop_ variable declarations in trigger
Mathias Mamsch - Sun Jun 10 06:22:10 EDT 2012 JoelKuehner - Thu Jun 07 11:04:03 EDT 2012
Hi Mathias,
Thanks for responding. I appreciate you chiming in.
I just want to be clear here that I do normally use the eval_ check to first check if a variable is installed. I didn't include it in my original post because I was showing the exact steps to reproduce my issue in the original post. The eval_ part isn't necessary to reproduce the issue. But normally, I have a Module-Post-Open trigger that simply checks if the variables are installed, and installs (and initializes) them if they're not.
With respect to the eval_ solution for checking if a variable is installed, I tried the exact code you suggested (which was basically the same as code I've already been using, since I got that code from one of these forums -- probably one of your posts -- a while back). It does not help. It checks if a variable has been installed, but doesn't help if the variably simply isn't assigned.
So it works if you use evalTop_ ("int Foo1 = 1"), but try it if you simply use evalTop_ ("int Foo1"). Now I realize that just doing "int Foo1" is not a good idea. But I'm not (intentionally) doing that. I'm issuing "int Foo1 = 1" in the trigger I mentioned above, but DOORS is taking away the assignment (after the evalTop_ completes) such that the variable is still installed but not assigned. So later I run the eval_ check, it tells me the variable is installed, I assume it's assigned (since I assigned it when I installed it), but since it's no longer assigned, I get the "unassigned variable" runtime error. As a matter of fact, the eval_ check itself gives me the run-time error when it executes the "print Foo1". Feel free to try it! Just issue an evalTop_ ("int Foo1"), then try your eval_ check and see what happens. You'll get the run-time error.
As to what I'm trying to accomplish, I will answer it, but please don't let this thread get off onto a philosophical debate about why I'm doing it. I know there are multiple solutions, but at this point I really want to focus on why DOORS is behaving like it is, rather than whether I should philosophically be using the evalTop_ in the first place. Though, depending on the outcome of this thread, I might decide not to use the evalTop_ for other reasons (i.e., it's broken). :)
I am simply trying to install some global variables. We have our own change-tracking functionality implemented. It uses a global variable to track which ChangeRequest the user is working against. That variable is initialized via a dialog box based on a module open trigger. That is all working great.
Then I wanted to add another modeless dialog box that opens when the module opens. Basically it's a floating custom menu to go along with the change-tracking. I wanted to use another global variable to track whether the dialog box exists. Basically, set a flag when the dialog box is created, clear the flag when the dialog box is closed. That way, later, if it's time to possibly re-open the dialog box, I query the global variable to see whether the dialog box already exists, in which case I just show it instead of re-creating it.
When I went to add the second flag, I was getting strange behavior, and spent about a day tracking it down. I went down lots of bunny-trails related to modal vs modeless, show() vs realize(), one trigger vs multiple, etc. Eventually I tracked it down to the issue I mentioned in my original post -- my evalTop_ variables that are installed via trigger are losing their assignments (all except the first). The dialog box and its context(s) have nothing to do with it.
We use DOORS in several sites in North America, Europe and India, sometimes on the desktop, sometimes remotely via Citrix (which we DOORS users have not admin access to), and in the future hopefully using web access. So I shy away from custom installations with custom startup files or custom menus, because it's somewhat difficult to maintain the configuration on all of those different platforms for different programs. It's often easier to just use triggers when the module is opened to set up whatever we need. We basically run a trigger install dxl script that reads our include files using fileRead(), concatenates them together with the trigger function, and installs that as the trigger. So no custom local or network files are necessary at all.
It would be great if you could install 9.3.0.6 (or 9.3.0.7) and let me know what you see. I expect you'd see the same as I do. Though even the results you cite are strange, and don't give me much confidence when using evalTop_ from triggers.
So the question now stands, where is the difference in our setup or the difference in our workflow? Did you try your code on a fresh DOORS installation with a fresh database (i.e. without any other triggers - for example on database level - installed)?
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|
Re: Multiple evalTop_ variable declarations in trigger
JoelKuehner - Mon Jun 11 10:23:58 EDT 2012 Mathias Mamsch - Sun Jun 10 06:22:10 EDT 2012
Bad News. I installed 9.3.0.6.93576 now and I still cannot reproduce the error. The variables print alright. I open DOORS, create a new Module, Save and Close. I install the trigger with your script (I change the module name to HRD before). I open the module, I get the same output as you. Then I launch the print statements from the DXL interaction window. I get the expected output (Foo1 = 1, Foo2 = 2). No error.
So the question now stands, where is the difference in our setup or the difference in our workflow? Did you try your code on a fresh DOORS installation with a fresh database (i.e. without any other triggers - for example on database level - installed)?
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
I just created a brand new module, called "Clean". I installed the trigger code. It did the same thing I posted in the first place. I.e., it did not work correctly. Then, for kicks, I tried opening the Clean module via our Citrix box (instead of via my local DOORS installation). Everything worked fine. I got the same output you did. Then I tried opening T1_SRD via Citrix. It too worked fine.
That's all somewhat plausible, since maybe there's some difference between the Citrix installation and my local installation. But then I restarted my local DOORS client. I opened Clean and it worked fine. Then I restarted DOORS and opened T1_SRD, and it worked fine.
So now I have no idea what's going on. I'm sure there's still an issue somewhere, and perhaps I'll flush it out when I get back to my real code, which is a lot more complicated than just Foo1 = 1 and Foo2 = 2.
I wonder if I have a bug in my code that somehow corrupts memory for a DLL or something that doesn't get unloaded/reloaded when I restart DOORS? Though I was seeing this issue across days, where I restarted my computer in between.
For now, at least I know that others aren't seeing the same issue with the simple code I posted. That alone is a data point.
Thanks for looking at this. For now, I cannot reproduce. But when it shows up again (I'm guessing it will), I'll try to dig some more and see what sequence causes it.
Joel
|
|
Re: Multiple evalTop_ variable declarations in trigger
Wolfgang Uhr - Mon Jul 06 03:31:12 EDT 2015 Mathias Mamsch - Thu Jun 07 09:23:53 EDT 2012
Hi Joel,
for DOORS 9.3.0.0.93199 i cannot reproduce the error. Here the Foo1 and Foo2 print alright. I think I will update to patch level 9.3.6 or 9.3.7 and see if the error persists. By the way, the way Louie suggests should be fine to test if a variable has already been installed on top level:
string sCode = "print Foo1"
noError(); string errMsg = eval_ sCode; string errMsg2 = lastError();
if (errMsg errMsg2 != "") print "Variable Foo1 has not been installed.\n"
Although it might not seem to be different for you can you change your code to:
The first thing that makes me courious is the fact, that when I install the trigger code and then subsequently open and close the module multiple times, then
-
the first time I get the correct printout
-
the second time I get "Foo1 already declared" etc errors
-
the third and all following times time I get the correct printout again.
Couriously when I delete the trigger and install the trigger again with different values for Foo1 and Foo2 they are printed with the NEW values instead of the old ones. What happens when you open/close the module multiple times? From what I see this code will do something to the DXL engine that is not good. Being able to declare the same variable on top level multiple times is not what I would expect.
By the way, what are you trying to accomplish? Install global variables in a script? For what purpose?
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
Hi Mathias
bool isValidEvalTopVariable(string sVariableName, string sVariableType) {
string sTestCode = sVariableType " iX = " sVariableName ";"
noError();
string sErrorMessage1 = checkDXL(sTestCode)
string sErrorMessage2 = lastError();
if (sErrorMessage1 sErrorMessage2 != "") {
print "Error in checkForEvalTopVariable: " sErrorMessage1 " - " sErrorMessage2 "\n";
return (false);
}
return (true);
}
To check if a variable exists I would prefer checkDxl, because here the code is not evalutated. In this case you can test a functions which returns integer in the same manner.
And formost the AutoDeclare_ interaction does not exists.
Best regards
Wolfgang
|
|
Re: Multiple evalTop_ variable declarations in trigger
pommCannelle - Mon Jul 06 04:12:24 EDT 2015
( hi !
I wonder if i'm the only one to use the directories DOORS\9.X\lib\dxl\startupFiles, DOORS\9.X\lib\dxl\config\formalFiles and co. to define my custom functions and variables ...
And what is the interest of the eval_ and evalTop_ functions ... i mean : is there an example of something that can not be done without these perms ??
Best regards! )
|
|
Re: Multiple evalTop_ variable declarations in trigger
Wolfgang Uhr - Mon Jul 06 04:38:17 EDT 2015 pommCannelle - Mon Jul 06 04:12:24 EDT 2015
( hi !
I wonder if i'm the only one to use the directories DOORS\9.X\lib\dxl\startupFiles, DOORS\9.X\lib\dxl\config\formalFiles and co. to define my custom functions and variables ...
And what is the interest of the eval_ and evalTop_ functions ... i mean : is there an example of something that can not be done without these perms ??
Best regards! )
You cannot debug structures in the sodius debugger without evalTop_
|
|